Custom Packages and Local XBPS Repositories

Pepvoid Builder can install local XBPS binary packages from custom_packages/. That directory also contains the source templates used to build Calamares and the Python libraries required by Pepvoid applications.

Repository layout

custom_packages/
├── calamares/                    # Calamares XBPS template
├── python3-customtkinter/         # Python library template
├── python3-darkdetect/            # Python library template
├── python3-plyer/                 # Python library template
├── python3-pystray/                # Python library template
├── python3-darkdetect-...xbps    # Built package for one architecture
└── x86_64-repodata                # XBPS repository index

Binary archives must match the target architecture (or be noarch) and the directory must have an XBPS repository index. During a real build, ChrootManager indexes the local archives with the isolated build-host xbps-rindex and adds the directory ahead of the configured repositories. Packages are installed only when they are in the selected package plan and a matching local archive exists. A missing custom-only package is skipped with a warning; it is not silently replaced with an unrelated package from an official repository.

Building the Python packages

The four Python library templates use pinned upstream source releases and checksums. Build them with the project’s isolated xbps-src pipeline:

python3 cli.py --build-python-packages

The command builds for the selected architecture (default x86_64) and publishes the resulting archives and index into custom_packages/. To rebuild and install these packages during an ISO build:

sudo python3 cli.py x86_64 --with-python-packages --mode real

To use packages already present in the indexed local repository, without rebuilding them:

sudo python3 cli.py x86_64 --with-python-packages --with-custom-repo --mode real

--with-custom-repo does not select every package in the repository. The python-libraries profile selects the four Python library packages; other packages must be selected by a software profile or explicit package option. The build checks that requested custom-only packages have an archive for the target architecture before installing them.

Python minor-version updates

The four libraries are pure Python. Their templates copy the module files from Void’s versioned site-packages directory into /usr/share/pepvoid/python3/site-packages. Pepvoid application launchers use /usr/local/bin/pepvoid-python3, which adds this stable directory to PYTHONPATH before starting /usr/bin/python3. This keeps these modules available when Void changes the Python minor-version directory.

Do not install compiled Python extensions in the shared directory. Native extensions must remain in Void’s versioned site-packages and be rebuilt for each supported Python ABI. Packaging layout changes require an XBPS revision bump and rebuilt binary archives. Systems with the initial revision 1 packages must upgrade to revision 2 or later (currently revision 3), or rebuild the system image, to migrate modules into the shared directory. Revision 3 also corrects the package maintainer contact. Editing a template alone does not migrate packages already installed on a running system; publish and install the rebuilt XBPS package.

Building another local package

For a separate custom package template, use the Void void-packages workflow:

git clone https://github.com/void-linux/void-packages.git
cd void-packages
./xbps-src binary-bootstrap

Create a template under srcpkgs/<package-name>/, then build it for the target architecture:

./xbps-src -A x86_64 pkg <package-name>

Copy the resulting .xbps archive into Pepvoid Builder’s custom_packages/ directory and index it for the matching architecture with xbps-rindex -a. Select the package in the build configuration or pass it as an explicit package; the local repository makes it available to XBPS but does not add it to the package plan automatically.